Subject: DCL comments on HPR-3 document

From: "Ray Bird" <[email-masked]>
Date: Tue, 25 Apr 95 15:40:52 EDT

The following questions/comments on the HPR-3 specification were
submitted by Mike Evans (DCL) in his April 21st note.  Our responses
are indicated by ***.

Ray and Lap

-----------------------------------------------------------
The following is our initial tranche of questions and points on the changes
in the HPR-3 specification.  As we progress integrating the changes (and
when Matthew gets back from his holiday next week!) we will undoubtedly have
further questions, but since we are only a few weeks away from the AIW I
thought it best to send these now.

Mike Evans (DCL)

 ----------------------------------------------------------

NCE Instance Identifiers (section 9.8)
 --------------------------------------

I understand the problem NCEIIs are trying to solve, but it looks like they
offer a very limited solution.  In particular, they don't work if either

 -  the second session is not activated through the same two RTP capable
   nodes,  for example, because the deactivated node is permanently
disabled,

    *** We agree this is a problem but not a serious one.  It will become
        even less serious as more products move up to HPR and will
        disappear when all nodes, including the endpoints containing the
        LUs, are upgraded to HPR.

   or

 -  the re-IPLed node changes its NCE (not changing NCEs over IPLs is
   recommended, not mandatory).

   *** True but products experiencing this problem can always fix it by
       not changing NCEs across IPLs.

The problem can be restated as a requirement for a path-switching node to
detect, within a reasonable space of time, that the partner RTP node has
been deactivated (and so has no record of the RTP connection).

We therefore propose an alternative solution as follows.

1)  If an RTP-capable node receives a Route Setup request triggered by a
path
    switch where it is indicated as the destination, but where the
destination
    NCE is unknown, it fails the Route Setup with a unique sense code
    indicating the fact that the NCE was unknown.

    *** We believe that most implementations will
        have a constant NCE (most likely one for the entire node) that
        will not change across IPLs, so the Route Setup will always be
        successful with your solution.
        Also, there is no Route Setup used for CP-CP sessions over RTP
        connections so this could never be used for them.

    *** However, all that said, we still believe this is a good idea
        because it supports nodes that change NCEs across IPLs.  Perhaps
        it can be incorporated as an addition into the existing
        algorithm.

2)  If an NCE receives a NLP containing an unknown TCID, a switching
    information segment, but no connection setup segment, he returns a
    connection fault segment indicating this fact using the RANR in the
    switching information segment, the received TCID and a CQF containing
    its network identifier, network name and NCE label.

    *** The CQF is always included with the Connection Setup segment.
        It is not included when only the Switching Information segment
        is present.  Therefore, since the partner NCE is not known a
        Connection Fault segment cannot be sent.
        Also, the TCID to be used to the partner is not known.

    *** Note that even if both the NCE (from CQF) and TCID were known it
        would still not solve the cases where the non-re-IPLing node does
        not immediately send a message with Switching Information
        (e.g., idle connections that have yet to detect the outage or
        connection endpoints that are passive and wait for the partner
        to do the path switch).

3)  If an RTP node is attempting to path switch, and receives this
connection
    fault segment, it immediately terminates the RTP connection (failing any
    sessions using the connection).

This solution results in the path-switching node deactivating the connection
on the first path switch retry after the partner node re-IPLs and reconnects
into the network (give or take topology propagation delays), which should be
sufficiently fast for most implementations.

This solution has several advantages over NCEIIs.

 -  It is simpler and easier to implement than NCEIIs (which is important
this
   close to CP status).

    *** Probably, the method you suggest is slightly, but not significantly
        easier to implement.

 -  It works with nodes that do not preserve NCE labels across IPLs.

 -  It works in many cases where the second session does not pass through
   the same two nodes.

However, it may still not work

 -  if the time between path switch attempts is large (which should therefore
   not be recommended)

    *** It is not unreasonable that Path switch
        times for low priority batch jobs could be large and that the time
        between those path switch attempts could also be large.
        We would prefer that the architecture not prohibit customer's
        from doing this.

 -  if the partner RTP node does not re-IPL (ie. is permanently disabled).

    *** This problem is the same for both solutions.  If the node dies
        path switch is attempted until the full path switch time expires.

Unfortunately, we can't come up with a solution general enough to work if
the partner RTP node is permanently disabled.  Aren't session limits
wonderful!

*** It should be noted that using NCEII's enables a node to terminate
    ALL existing connections to the re-IPL'd node at once.  This includes
    connections in idle state, connections waiting for
    the partner to do the path switch, as well as connections actively
    attempting path switch.

*** We agree that this is not an easy problem to solve.  The NCEII
    solution is now considered to be part of the base HPR architecture
    and the NCE Instance Identifier CV 39 must be included in the
    formats as currently described.  However, we certainly welcome any
    improvements to this algortihm as a tower.

Persistent ANR Labels (section 7.1.3)
 -------------------------------------

This section seems to 'sit on the fence' and not recommend either of the two
proposed solutions to the ANR misrouting problem. Is either solution
recommended, mandatory, or is it an implementation option? If it is intended
as an implementation option, then the specification should say so.

*** It is an implementation choice.

We also propose a third, hybrid, solution to the problem, which ages ANR
labels when the link is deactivated, but if the link is reactivated during
the ageing period, uses the same label for that link.  This has the benefits
of both the proposed solutions (if the aging period is sufficiently large)
with none of the disadvantages.

The specification should also note some of the possible serious consequences
of ANR misrouting (since in most of the obvious cases, the connection just
path switches).  The worst case I could come with is when, in problem 1,
Link A and Link B are parallel links to the same adjacent node, but Link A
is secure and link B is non-secure.  Once the misrouting happens, no
path-switch will occur, and potentially sensitive data is being sent over a
non-secure link!

*** Agree with all of the above comments - will update the document accordingly.

Route Setup
 -----------

The HPR-1 spec. describes how a new RTP connection can make use of the
routing information associated with an existing RTP connection with the same
RSCV, thus avoiding Route Setup.  This is shown as condition B in figure 9-3
(page 9-7).

The HPR-3 spec. shows no such shortcut in the corresponding diagram (figure
9-6, page 9-14), although there is no reference to a change in the preface.
The "session initiation logic" section (figure 9-7, pages 9-18 and 9-19) is
consistent in that it shows Route Setup always being performed when a new
RTP connection is set up.

The HPR-2 spec. is consistent with the HPR-3 spec., but there is no mention
of this change in the change pages of HPR-2 or HPR-3.

Has this option really been removed?  Is it because the COS/TPF can now be
changed on the Route Setup reply (by an intervening border node)?  If that
is the case, isn't it still ok to avoid the route setup if the route does
not path through a border node (easily verified by looking at the RSCV)?

*** - Yes the option has really been removed.  We kept discovering cases
      where it wouldn't work.  First was CNN, then Border Node, then
      other subnets (like NBBS).  Also, we discovered you couldn't reuse
      the routing information in the case where the partner established
      the connection because you didn't know the ANR labels for the
      path from the partner to you and so couldn't provide reverse
      route information on the Connection Setup.  Because of all these
      exceptions we just decided to simplify things and never reuse
      route information.  This also provided a safe-guard against any
      future changes cases that would require Route Setup.